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A system and method for conducting commerce over a distributed network (108) to manage merchant and product information in an 
electronic shopping basket (148), payment source information in an electronic wallet (140), and shipping address infcmnation in an electronic 
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shopping options. The HT^^O^-coded Web documents contain ftmction-calling information by which consumer selected options Invoke 
shopping related functions on eitiier tfie merchant (server) computer (104) or die consumer (client) computer (102). 
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SYSTEM AND METHOD FOR CONDOCTING COMMERCE 
OVER A DISTRIBUTED NETWORK 

Priority 

This appGcation claims priority from the provisional patent application No. 60/020,891 mafled Jurta 28, 
1996, titled. 'SYSTEM AND METHOD FOR CONDUCTING COMMERCE OVER A DISTRIBUTED NETWORK." 

Backpround of the Invention 

Fteld of the Invention 

This tnventnn relates to distraiuted computer networks such as the Internet More particulariy, this 
invention relates to cGent-server software components for aliowing consumers to purchase goods and services from 
merchants over a distributed networic 
Description of the Related Art 

Etectronic shopping systems currently exist whKh allow users to remotely purchase goods and services from 
a variety of different on*&ie merchants over a distributed computer networic such as the Internet With systems of 
this type, the on-Bne merchants typicafly pub&sh on-lkie catalogs which can be viewed interactively by the end users 
of the network using a personal computer. These catalogs inchide pictures, textual descriptions, and pricing 
information with respect to the products and/or servkes of the respective merchants, and typically include on-fffie 
forms for alowing users to return purchase orders to the merchants over the network. In Worid Wide Web CWeb') 
based implementations, the on-fine catalogs are in the form of hypertext documents which are hosted by the Web 
sites of the respective merchants, and the catalogs are accessed uang a standard Web browser application which 
runs on the user computer. (A Web site b an Internet-connected computer or computer system which runs server 
software for serving information usmg the standard protocols of the Worid Wide Web.) In other implementations, 
the on-line catalogs may, for example, be hosted by a centraSzed computer of an on-fine services network, such as 
MSN, or by an Internet site which is accessed using a proprietary cfient appfication (such as the cGent application 
of eShop Inc.). 

Summary of the Invention 

Some computer-based shopping systems currently exist which allow the user to selecthrely store product 
information (and various other types of 'shopping-state" information) for subsequent recall and use. This allows the 
user to rapidly bring up the information viewed during previous visits to the merchant site, and to essentially continue 
the shopp'mg session where the user teft off. Unfortunately, these systems generally store the product information 
on the server side only (e.g., on the merchant Web site), and do not include the necessary client and server software 
components for allowing the user to selectively store the product information on the consumer computer. This 
deficiency in the software architectures of existing computer-based shopping systems imposes several Emitations on 
consumers. First, it makes it difficult for the consumer to gather product information from multiple merchants into 
a common, local storage area. This, in turn, makes comparison shopping very difficult: the consumer generally 
cannot, without considerable inconvenience, compare fike products (or services) from different on-line merchants. 
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Second because the infonnation n typically retained by the merchant site for a imited period of time (typically a 
few days), the consumer is under a time constraint to make use of the stored product information. Moreover, many 
hundreds or thousands of requests by consumers to store product informatbn on a merchant's site may degrade the 
merchant site's response time, and create other probtems related to the heavy storage burden. 
5 Abo, because existing computer-based shopping systems typically host most or al transact»n options on 

the server side, the shopping experience often differs from merchant site to merchant site. Specifically, as the 
consumer moves from one merchant site to the next, the options presented to the consumer and the steps required 
to navigate and effectively use those options often differ stgnifrcantly. Thus, to browse product information and 
purchase products and/or services offered by multiple merchants, consumers often must adapt to and learn the 

10 options offered by each merchant site. 

Another problem with existing computer-based shopping systems is that they often require user entry of 
purchase infonnation and shipping information upon every purchase, or at least require consumers to identify 
themsehres during each shoppmg session. These restrictions are time consuming, tedious, and bothersome. Further, 
repeated entry of payment information or shipping information increases the likelibood that a consumer wil mistakenly 

15 enter incorrect information. 

The present invention addresses these and other problems with existing electronic shopping systems. In 
accordance with the invention, an etectronic shoppmg system is provided which makes use of the existing cEent and 
server software components and protocols of the World Wide Web, and which adds various cfent-side functronafity 
for afbwing users to store, view, and process product information (gathered from merchant Web sites), payment 

20 information, and shipping information on the user computer. The system inchides a specialized cEent application 
(referred to as the "commerce cOentl which runs on the consumer computer m conjunction with a standard Web 
browser. The commerce cEent communkates witii a speciaized commerce server (which runs on the merchant Web 
site in conjunction with a Web server) using a bhdirectional function calSng protocol. Hypertext (HTML) catah>g pages 
served by the merchant Web site, as weD as "user interface* hypertext documents stored on the us^ computer, 

25 inchide embedded f unctbn calls which can be selectively invoked by the consumer whBe viewmg the hypertext pages 
with the Web browser. Using these embedded function calls, the user can perform actions such as: request pricing 
or inventory information on a particular product from die merchant Web site; selectively store product information 
within a cGent-side shoppmg basket; view the contents of the shopping basket; and transmit encrypted shipping 
and/or payment infonnation (stored on the consumer computer) to the merchant Web site. 

30 hi accordance with one aspect of the invention, there is thus provided a method for gathering and 

comparing product information over a distributed network. The method comprises the steps of (a) sending a first 
hypertext document over the distributed network to a user computer, the first hypertext document comprising a 
description of (i) a first product, (ii) a selectable product gathering option, and fio) function-calling information 
associated with the product gathering option; (b) displaying the first hypertext document to a user via the user 

35 computer and monitoring user input for setectkin of the product gathering option; and (c) responding to selection of 
the product gathering option by calling an executable function specified by the function-calling information, tiie 
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function storing the description of the first product to a data storage area accessBite to the user computer. Another 
embodiment of thb aspect preferably comprises the further steps: (d) sending a second hypertext document over the 
distrfliuted network to the user computer, the second hypertext document comprbmg (i) a descrfption of a second 
product (n) a selectable product gathering option, end (iS| functton-caffing information associated with the product 
5 gathering option; (a) displaying the second hypertext document to the user via the user computer and monitoring user 
input for selection of the product gathering option; (f) responding to selection of the product gathering option by 
caDing a second executable function represented in the function-caffing information, the function stormg the 
description of the second product to the data storage area; (g) displaying a product comparison option to the us^ 
via the user computer and monitoring user input for selection of the product comparison option; and (h) respondmg 

10 to selection of the product comparison option by retrievmg from the local storage area the descrqition of the fffst 
product and the description of the second product and by f omiatting the descriptions and displaying the descriptions 
to the user via the user computer. 

Another aspect of the present invention is a metiiod for using a Web browser to manage local data. The 
bcal data is stored on a computer storage medium accessible to the user computer. The method comprises the steps 

1 5 of: (a) recehring with the Web browser an HTML document (HyperText Maricup Language) ctmipristng a user-selectable 
view option and function-caffing information associated with the view option; (b) displaying the HTML document to 
a user via the user computet the display mchiding the view option; (c) monitoring user input for selection of the view 
option; and (d) responding to selection of the view option by calling a function represented in the function-calEng 
mformation, the function accessing and formatting the local data and displaying the local data to the user. 

20 Brief Descriotion of the Drawinos 

, These and other features of the invention are described below with reference to the drawings of a preferred 

onbodiment of a computer-based shoppmg system, which is intended to fflustrate and not to bnit the invention, and 
in which: 

Figure 1 Sustrates a consumer computer communicating with two merchant Web sites of the system in 
25 accordance with the present invention- 
Figure 2 flhistrates a preferred protocol for transferring function call requests and responses between the 

consumer computer and a merchant Web site of the system using the HTTP message stream between a standard 

Web browser and a Web server; 

Figure 3 illustrates a preferred software architecture for the merchant Web sites of the system; 

30 Figure 4 illustrates a preferred software architecture for the consumer computers of the system; 

Figure 5 illustrates data structures accessed and manipulated by shopping basket wallet and address book 
objects on the consumer computer; 

Figure 6 iOustrates the steps performed in adding mformation (served by a merchant Web site) about a 
product to the shopping basket ob^ct 
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Figure 7 iBustrates the steps perfornied in viewing product information stored within the shopping basket; 

F^ure 8 illustrates the steps perfornied in deleting a product from the shopping basket; 

Figure 9 iBustrates steps perfornied h viewing detaBs about a product from the electronic shopping 

basket; 

5 Figure 10 iBustrates the steps performed in viewing and manipulating payment source data in the waQet 

object on the consumer computer; 

Rgure 11 Shistrates the steps performed in viewing and manipulating shipping address data in the address 
book object on the consumer computer; and 

Figure 12 iBustrates the steps perfonned in purchasmg selected products from merchant Web sites of the 
10 system over a distrSiuted network. 

Detaited Descrrotion of the Preferred 6nbod&nCTt 
The present invention concerns electronic shopping and provides the ability to use a personal computer to 
compare and purchase products offered for sale via a distra)uted network. The invention is embodied within a 
computer-based shopping system which utilizes the existing protocols and components of the World Wide Web. The 
15 computer-based shopping system b descra)ed in detai herem. 

In the preferred embodiment, the system inchides a "commerce cfont* process which runs on a consumer's 
computer in conjunction with a standard Web browser. The commerce client communicates over the Internet with 
a "commerce server' (using a bidirectional function calling protocoQ executmg on a merchant Web site, in a preferred 
embodiment, the commerce cfient inchjdes f unctnnality similar to that of a shopping basket, a waBet, and an address 
20 book, and the commerce server inchjdes functionality for providing a variety of commerce-related services (such as 
accessing or returning product information, calculating taxes, processing orders, etc.). 

The commerce cSent and commerce server operate together to aBow a consumer to gather product 
information from any number of merchants while the consumer's computer is connected to the Internet The 
conmierce client also pemiits the consumer to perfomi comparison shopping by reviewing product information 
25 gathered from various merchants. Thb product comparison can be performed by the consumer at any tone (e.g., while 
off-Gne) and ov^ any length of time, regardless of whether the consumer's computer is connected to the Internet. 



A user unfamiliar with the operation of a computer-based shopping system which embodies the present 
mvention can access instructional information (or appGcation help) by selecting a help option. The instructional 
30 information b stored on one or more HTML-coded Web documents which are retrieved and displayed according to 
the user's needs. 

A computer-based shopping system embodying the present invention permits a user to purchase products 
from an on-line merchant The consumer uses the commerce client to authorize payment, select a payment source, 
select a shipping eddress (none of which require network connection) and abo to place an order to the merchant 
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for tba selected product A network connection is estabSshed for the commerce cfont to communicate the order 
to the commerce server. The payment and shippmg information is protected from third party discovery using 
encryption technology. 

The following sections and subsections describe the invention in more detait 
5 A. Glossary of Tenns and Acronym 

B. Example Conqiutar-Based Shoiqdng Session 
C Comminicatioa Between Cononerce Client and Commerce Server 
0. Software Architecture of Merchant Web Site 
L Software Architecture of Consumer Computer 
10 A. Gfossanr of Terms and Acronyms 

The foflowing terms and acronyms are used throughout the detaOed description: 
Internet A coDection of interconnected (pubfic and/or private) networks that are Gnked together by a set 
of standard protocols (such as TCP/IP and HTTP) to form a gtobal, distrSiuted network. (WhOe this term 
is intended to refer to what is now commonly known as the Internet, it is also intended to encompass 
15 variations which may be made m the future, including changes and additions to existing standard protocols.) 



World Wide Web rWdi"). Used herein to refer generally to both (i) a distributed collection of interlinked, 
user*viewabla hypertext documents (commonly referred to as "Web documents" or "Web pages") that are 

20 accessible, via the Internet and (ii) the cfient and server software components which provide user access 

to such documents usmg standardized Internet protocols. Currently, the primary stendard protocol for 
aBowing applications to locate and acquire Web documents is HTTP (discussed below), and the Web pages 
are encoded using HTML (also discussed below). However, the terms "Web" and "Wortd Wide Web" are 
intended to encompass future markup languages and transport protocols which may be used in place of (or 

25 in addition to) HTML and HTTP. 



Client-Server. A model of interaction in a distributed system in which a program at one site sends a 
request to a program at another site and watts for a response. The requesting program is called the 
"cfient" and the program which responds to the request is catted the "server." In the context of the WorU 
30 Wide Web, the cRent is a "Web browser" (or sbnply "browser") which runs on a computer of a user; the 

program which responds to browser requests by serving Web pages is commonly referred to as a "Web 
server," 



35 



TCPIIP (Transmission Control Protocolflntemet Protocol). A standard Internet protocol (or set of 
protocols) which specifies how two computers exchange data over the Internet TCP/IP handles issues such 
as packetization, packet addressing, handshaking and error correction. For more inf ormatnn on TCP/IP, see 
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Volumes I II and III of Comer and Stevens, Intemetworkmo with TCP/IP. Prentice HaH Inc., ISBNs 0-13- 
468505-9 (vol H 0'13-1255274 (voL 11), and 0-13474222-2 (voL IIIK 

HTML (HyperText Markup Lanouaoe). A standard codmg convention and set of codes for attaching 
5 presentation and Gnktng attributes to informational content within documents. (HTML 2.0 is currently the 

prmiary standard used for generating Web documents.) Durng a document authoring stage, the HTML 
codes (referred to as "tags") are embedded within the informational content of the document. When the 
Web document (or "HTML document") is subsequently transferred from a Web server to a browser, the 
codes are int^reted by the browser and used to parse and display the document In addition to specifymg 
10 how the Web browser is to display the docununt, HTML tags can be used to create finks to other Web 

documents (commonly referred to as "hyperiinks"). For more information on HTML, see Ian S. Graham, The 
HTML Source Book. John Wiley and Sons, Inc., 1995 (ISBN 047M 18944). 

Port or Port Number. (Also referred to as "socket number.") In the context of the Internet, a numerical 
15 identifier (normafiy provided in conjunction with an IP address) which is used by TCP/IP to direct incoming 

data to a particular appOcatmn. Certain ports have been reserved by the Internet Assigned Number 
Authority (lANA) for certaki applications. For example, port 80 is reserved for HTTP, and is used on Web 
sites to direct incoming traffic to a Web server. (See "URL" below.) 

20 URL (Unifonn Resource Locator). A unkiua address which fully spectfes tiie location of a file or other 

resource on the Internet. The general format of a URL is protocot/Zmachine addresstport/path/filename. 
The port specification is optkmai, and if none is entered by the user, the browser defaults to the standard 
port for whatever service is specifffid as the protocoL For eiampla, if HTTP b specified as the protocol, 
the browser wil use the HTTP default port of 80. 

25 

HTTP (Hypertext Transport Protocol). The standard Wortd Wide Web client-server protocol used for the 
exchange of information (such as HTML documents, and cfient requests for such documents) between a 
browser and a Web server. HTTP includes a number of different types of messages which can be sent 
from the client to the server to reiquest different types of server actions. For example, a "GET" message, 
30 which has the format GET <URL>. causes tho server to return the document or file tocated at the 

specified URL 
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HTTP POST. A type of HTTP message which is used to request that the Web server accept information 
from the Web client This mformation may, for example, be in the form of a message to be posted to a 
newsgroup, or a database submission which is executed by a CGI script (See 'CGI" below.) 
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MIME (Muitiporpose Intenmt MuMiindia Extensions) Type. A file extension or attachment which 
specifies the type or format of the file (e.g., HTML, text graphics, audio, etc). MIME typing aDows the 
Web browser to determine how to process a fib that is receded from a Web server. For example, a file 
of MIME type HTML (extension "Jitm" or "Jitml") will be (fisplayed by the browser, wb3e a file of MIME 
type X-WAV (extension ".wav") wiD typically be passed to an audio player which can handle the Microsoft 
WAV format Standard Web browsers come pre-configured to handle popular MIME types. In addition, 
standard Web browsers can easBy be conrpred by the user to handle new MIME types; this typicaDy 
invohres specifying the fDe extension of each new MIME type, and specifying the path and fbname of the 
application (referred to as a 'MIME handler") to which files of such type shouU be passed. 

Internet Firewall A security system placed between the bitemet and an organization's networlt (such 
as a LAN) to provide a barrier against security attacks. Internet fffewalls typically operate by monitoring 
inconring andfor outgoing traffic to/from the organization's network, and by alowing only certain types of 
messages to pass. For exampte, a ftrewall may be configured to aBbw the passage of all TCP/IP traffic 
addressed to port 80, and to block aB other traffk. For more information of bitemet FirewaBs, see 
Chapman and Zwicky, Buildino Internet Ffrewalls. Q'Reiy pubfishing, 1995 (ISBN 1-56592-1244)). 

CGI (Common Gateway Interface). A standard interface which specifies how a Web server (or possibly 
another information server) launches and interacts with external programs (such as a database search 
engine) in response to requests from ctents. With CGI, the Web server can serve information which is 
stored in a format that is not readable by the cSent and present such informatkm in the form of a cGent- 
readable Web page. A CGI program (calted a "CGI script") may be invoked, for example, when a Web user 
fins out an on-screen form which speciftes a database query. One disadvantage of CGI is that it generally 
requires the launchmg of a separate process for each client request recehred. For more information on CGI, 
see Ian S. Graham, The HTML Source Book. John Wley and Sons, Inc., 1995 (ISBN 047M 18944), pp. 
231 278. 

ISAPI (Internet Server Application Program Interface). Microsoft's mterf ace for allowing a Web server 
(or other mf ormation server) to launch and interact with externa) programs in response to requests from 
cEents. ISAPI programs are in the form of dynamic link libraries (DLLs) which run in the same process 
space as the Web server. Thus, ISAPI performs a similar function to that of CGI, but without requiring 
the launching of a separate process. Documentation on ISAPI is avalable from Microsoft Corporation as 
part of the Microsoft Internet Information Server Software Development kit 



B. Example Computer-Based Shopoinq Session 
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Thb section provides en iltustration of a hypothetmal computer-based shopping session wherein features 
of the present mvention are used. Hgure 1 Sustrates a consumer computer 102, a first merchant site ("merchant 
site A") 104, and a second merchant site ("merchant site B") 106, each connected to the Internet and utffizing the 
World Wide Web ("WWW") 108. Merchant site A 104 and merchant site B 106 host shopping-oriented transactions 
5 to advertbe and sell products over the bitemet The consumer computer 102 and merchant Web sites 104, 106 
run cEent and server software applications which allow a consumer to browse product information advertised over 
the WWW, gather mfomnation about products and merchants, selectively store the product and merchant information 
in a c6ent shie database, compare product information from different merchants, and purchase products sold over 
the Internet 

10 The consumer computer 102 comprises a processing unit 110, a data storage area 112. as weB as a 

monitor 114, keyboard 116, and a mouse 118. A standard Web browser 120 (such as, for example, Microsoft 
Internet Explorer 10 or Netscape Navigator 2.0) and a specbbed commerce cCent process 122 execute on the 
processing unit 110. 

Merchant site A 104 comprises a processing unit 124 and a data storage area 126. A standard Web server 

15 128 (such as Microsoft Internet Infonnatton Server 1.0) and a specialized commerce server 130 execute on the 
processing unit 124. Likewbe, merchant site B comprises a processing unit 132 and a data storage area 134. A 
standard Web browser 136 executes on the processmg unit 132, as does a specialized commerce server 138. 

A consumer using the consumer computer 102 stores payment source information 140 such as a credit card 
number, expiration date, and issuing bank to the storage area 112. The consumer suppfies a password in association 

20 with the payment source information. The password is used not only to prevent future unauthorized accesses, but 
also to encrypt the payment source information. The payment source information represents preferred sources of 
cash and/or credit for purchasing products andior services. The commerce cBent 122 writes encrypted payment 
source data to the data storage area 112. After entermg the payment source information once and verifying its 
accuracy, the mformation persbts on the consumer computer 102 without requking re-entry by the consumer. The 

25 consumer designates one of the payment sources stored as the preferred payment source. 

The consumer also stores shipping address information 142 to the storage area 112 via the consumer 
computer 102. Shipping address information intficates preferred destinations for delivery of products and inchides, 
for example, a personal re^ence address, a P.O. Box, or a business address. Again, the commerce cEent 122 writes 
shipping address information 142 entered by the consumer to the storage area 112. After the preferred shippmg 

30 destinations are entered, they need not be entered a second time. As done with the payment source data, the 
consumer designates one shipping address as the preferred shipping address. 

A consumer uses the consumer computer 102 to shop for products such as, for example, an audio compact 
disc, a downloadable software program, a rare coin, or a refrigerator, offered by merchants via tiie Wortd Wkle Web 
108. Using the example of shopping for a refrigerator, the consumer uses the consumer computer 102 to establish 

35 a connection to the Internet and uses a Web browser to navigate Worid Wide Web 108 sites. Connecting to the 
Internet and browsing the WWW is well known and the steps invohred will not be further described. 
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The consumer uses the Web browser 120 to access a merchant site A 104 on the WWW. The Web server 
128 of merdiant site A 104 responds to the access initiated by the consumer computer 102 by retrieving a first 
HTML document 0.e., a collection of data encoded m compOance with the Hyper-Text Markup Language) from the 
set of HTML documents 144, and by then transmitting the first HTML document to the Web browser 120 of the 
5 consimier computer 102. 

The Web browser 120 interprets the HTML document and creates on the monitor 114 a page-oriented 
representation of the document The consumer views the document on the monitor 114. The document may, for 
example, present textual infonnation to the consumer describing merchant site A 104 such as the nature of products 
offered and the forms of payment accepted in filfing orders for the products. The consumer may, for exampte, 

10 discover that merchant site A offers refrigerators for sale and accepts VISA for payment 

Generally, consumer-selectable options ('hypertext inks") are also presented within the HTML document 
which, if selected by a consumer using the mouse 1 18 or the keyboard 116, cause the consumer computer 102 to 
transmit requests to the Web server 128 to retrieve and transmit additional HTML documents providing related or 
more detaied information. The consumo- navigates additional hypertext links and browses additunal HTML 

15 documents summarizing features of refrigerators sold by merchant site A. 

The constmier decides that one of the refrigerators offered by merchant site A b well-suited to the 
consumer's needs. A number of attrftutes are presented to the consumer, each attrAute capable of being set to 
one of a number of vahies. Thus, for example, the user sets a color attribute to "Egg Shell White," sets an indoor 
water spout attribute to "No," and an automatic ice-maker attribute to "Yes." The consumer then selects an option 

20 labeled, for example, "Add Item to Shopping Basket." The Web browser 120 directs a correspondmg message to 
the commerce cBent 122 causing information about the selected merchant A refrigerator, inchiding the attributes 
selected, to be stored in a gathered products database 148. (The protocob and software cimiponents which enable 
thb type of operation to be performed are deserved in the following sections.) Such information bcludes, for 
exampte, a picture of the refrigerator, cubic foot capacity, temperature range, energy usage, manufacturer's warranty, 

25 price, the attributes set by the consumer, the URL of merchant site A, and abo tnchides a preferred payment source 
and a preferred shipping eddress. The consumer then ends the shopping sessmn with merchant site A either by 
accessing a different Worid Wide Web site or by directing the consumer computer 102 to terminate the network 
connection to the Internet 

Two days later, the consumer, again having tkne to shop, directs the consumer computer 102 to connect 
30 to merchant site B via the Worid Wide Web. Merchant site B abo offers refrigerators for sale. After navigating 
through HTML documents deserving the features of the refrigerators sold by merchant site B, the consumer selects 
a refrigerator, sets the refrigerator attributes as desired, and invokes the "Add Item to Shopping Basket" option. 
The commands to accomplish thb are the same as those required to add the mf ormation about the merchant site 
A refrigerator to the shopping basket The commerce cGent 122 responds to the invoked option by adding 
35 information about the merchant site B refrigerator to the gathered products database 148. The consumer then 
terminates the shopping sessun with merchant site B 108. 




wo 98/21679 PCT/DS97/20fiZ4 

Three weeks later, the consumer uses the consumer computer 102 to compare the information about the 
merchant she A refrigerator and the merchant site B refrigerator. The consumer does not need to connect to the 
World VWde Web to compare the two refrigerators. The consumer invokes an option entitled, for example, "View 
Items m Shopping Basket" The commerce cGent 122 extracts the information about the two refrigerators from the 
5 gathered products information 148, and fomiats the information such that the consume can view it on the monitor 
1 14. After we^hing the features, warranties, and prices of the two ref r^erators, the consumer decides to purchase 
the merchant site A refrigerator. 

The consumer then authorizes access to the payment source and address infomiation stored on the 
consumer computer by entering a password known only to the consun^r. After the consumer enters the password, 
10 the commerce cfient 122 accesses the payment source information 140, decrypts the information, combines it with 
information about the merchant A refr^erator to assemble a goods and services order ("GSO'T. The GSO is then 
encrypted and inchided as part of an HTTP POST message which is sent to the URL of merchant A. Merchant A 
receives the message, decrypts it, processes the order, and ships the product to the consumer's specified shipping 
address. 

15 A few years after purchas'mg the refrigerator, the consumer exam'mes a product purchasing history to 

determine, for example, whether the refrigerator b sti under warranty. The electronic shopping basket retains a 
complete, browsable history of aH products purchased. 
C. ConmHinication Between Commerce Cfient and Commerce Server 

The present invention extends the functkmaGty of the standard Web browser 120 by adding shopping-related 

20 features, namely, a shopping basket in which product infomiation can be gathered, a wallet in which sources of 
payment can be stored, and an address book in whkh shipping addresses can be recorded. The standard Web 
browser 120, so extended, offers consumers an extremely convenient and consistent method of shopping for products 
over the Worid Wide Web. This section d8scr3>es a method for a Web browser to call functions on both its own 
tacal computer and abo on a computer executing a Web server. AddttkmaOy, a method b described for aDowmg a 

25 Web server to call functions on a computer executing a Web browser. 

Figure 2 iDustrates communication between a consumer computer 102 and a merchant computer 202. A 
consumer accesses a merchant computer 202 on the internet 204 via a consumer computer 102. The consumer 
computer 102 includes a standard Web browser 120, and the merchant computer 202 includes a Web server 128. 
The Web browser 120 and the Web server 128 use the HTTP protocol to communicate with each other over the 

30 Internet 

The Web server 128 running on the merchant computer 202 accesses a local store 144 of HTML documents 
(abo commonly referred to as "Web documents" or "Web pages"). When the Web browser 120 on the consumer 
computer 102 requests an HTML document, the Web server 128 retrieves the HTML document and transmits it to 
the Web browser 120 on the consumer computer 102 where it b viewed by the consumer. These documents 
35 typically inchide information about the merchant, as well as information about the products soU by the merchant 
(including pictures and descrqitions of products and product prices). 
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To provide more sophisticated shopping transactions between consumers and merchants, software dedicated 
to providing consumer-oriented shopping functions (the commerce cEent 122) executes on a consumer's computer, 
and software dedicated to providmg merchant-oriented functions (the commerce server 130) executes on a merchant 
computer 20Z One objecthre of the present invention is to provide both a commerce cBent 122 running on the 
consumer computer 102 which communicates directly with the Web browser 120, and a commerce server 130 
runnng on the merchant computer 202 which communicates directly with the Web server 128. 

The comnrarce cBent 122 and the conunerce SOTer 130 utifize the tntemet-based communication between 
the Web browser 120 and the Web server 128 to comnumicate with each other. An extensible Web function-calling 
protocol rWFCP*) permits the commerce client 122 and the commerce server 130 to pass functbns calls to each 
other by embedding the function calls bi data exchanged via the Internet by the Web browser 120 and the Web 
server 128. As ihistrated in Figure 2. the Web function-caDing protocol effecthrely "tunneb** function-caBing 
information (requests and responses) through an HTTP message stream (shown in dashed Bnes) between the standard 
Web browser 120 and the Web server 128. One sigraftcant benefit of the use of HTTP b that it allows the 
consumer computer 102 to communicate with merchant Web sites from behind Internet f^ewalls 214 which permit 
passage of HTTP traffic 

The Web server 128 serves HTML documents which Inchide embedded function caing informatnn. This 
function caing niformation is embedded in a hidden form usmg standard HTML tags, and b provided in a predefined 
format (specified as part of the WFCP) that b recognized by both the commerce client 122 and the commerce server 
130. Generally, the embedded function caffing information corresponds to consumer-selectabte options (e.g., 
hyperBnks or buttons) within HTML documents to aDow a consumer to initiate cEent-to-server function caOs across 
the Internet by selectmg (with mouse or keyboard) transaction options. 

Figure 2 Qhistrates an HTML document 206 be'mg dbplayed by the Web browser 120. The HTML document 
206 includes a consumer-selectable button 208 associated with a textual description (such as "buy," "update 
shopping basket," "retrieve price information," or "retrieve account information") of a correspondmg action to be 
performed. When the consumer cRcks on thb button, corresponding f unction-caffing mf ormation b passed across the 
bitemet as a standard HTTP POST message from the consumer computer 102 to the merchant computer 20Z 

The functbn caing information for making a corresponding function call typically tncbdes the name of an 
object an ob^ct interface, a method, and an argument Est. If the button 208 actuates a "Calcubte Tax" option, 
the corresponding function-calOng information associated with the button may, for example, tnchide the text 

0BJECT-MSTaxEngine.1 

INTERFACE-ITaxCalculation 

METHOD-CalculateTaxDue 

ARGS-arglbt 

Thb functbn-caDing information b provided in the HTML document along with a target URL (of the merchant Web 
site 104, 106) such that an HTTP POST message containing the information wDl be sent to the URL if the consumer 
clicks on the button 208. One exampb of an HTML-coded form of the HTTP POST message b: 
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<HTML> 

< !-VffCP FORMATTED CALL--> 
<FORiyi ACTION-http://www.merchantcoin/mig.dll 
METHOD --POST 

ENCTYPE-"appGcation/x-wwwf ornMirbncoded" > 

< INPUT type-hidden name-OBJECT vahie-MSTaxEngine.1 > 

< INPUT type-hidden name-INTERFACE vatue-ITaxCalculation> 
< INPUT type-hiddwi name-METHOD value-CalculateTaxDue> 

< INPUT type-hUden name-ARGS value-argEst> 

< INPUT type-submit vatue-'Cakulate Sales Tax"> 
</FORM> 

<iHTML> 

Although the target URL in this example corresponds to the Web site that is the source of the HTML document, the 
target URL could be that of a different Web site. 

Thus, when the consumer cScks on the button 208, the Web browse 120 generates an HTTP POST 
message coded using HTML and sends the HTTP POST message to the URL of the merchant Web site 104, 106. 
This message includes function-calling information (ob^t interface, method and arguments) to invoke a method Tie., 
a software callable procedure or function) of a method library 212 on the merchant computer. If muhqile function 
cans were &iked to the button 208, the HTTP POST message would include the function-calfing information for each 
such function call. 

Upon receipt of the HTTP POST message, the Web server 128 parses the message, mvokes the commerce 
server 130 Of not already executmg) and passes the function-calling information to the commerce server 130. The 
commerce smer 130 then invokes the specified object and passes the arguments to the specified method using the 
specified interface; the commerce server 130 thereby makes the function call on behalf of the commerce client 12Z 
Depending upon the method called, the function call may, for example, invohre a query of and/or an update to a 
merchant database. 

This function call will typically produce a response which must be communicated to tfie consumer computer 
10Z (In the context of electrons shopping, the response message may include, for example, price or inventory 
information for a particular product, or the result of a tax calculation requested by the consumer.) The response 
may include a function call or other information directed specifically to the commerce cGent 122. The Web browser 
120 receives aB data transmitted from the merchant computer 202 to the consumer computer 10Z However, some 
of the data recehred by the Web browser 120 is further routed to the conmierce client 12Z 

The Web server 128 transmits data to the consumer computer 102 by first packaging the data as a MIME 
message and then sending the MIME message across the Internet from the Web server 128 to the Web browser 120. 
If the response message is oi the form of an HTML response to be displayed by the Web browser 120, the MIME 
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type of the message wil be HTML If, on the other hand, the response message is directed to the commerce cfient 
122 (such as when the response includes non-HTML product information^ the response message wlB be tagged with 
a MIME type which corresponds to the commerce client 122, causing the Web browser 120 to forward the message 
to the commerce cBant 122. 

In the preferred embodiment the MIME type associated with the commerce client is "x-ishopper." The 
message generated on the server side may include information to caB a function on the consumer computer 102, in 
which case the MIME nrassage wia include function-caQing information. This server-to-cGent function-calling 
information specifies the object, method, interface, and arguments of the client-side function caD and is specified 
within the MIME message using the same format (Ihistrated above) as used for cGent to-server function calls. 

Upon receiving a MIME message of type "x-ishopper," the Web browser 120 strips off the MIME headers 
and passes the message to the commerce cBent 122. As described further below, the commerce cfant 122 acts 
as a MIME handler for messages of type "x-ishopper." The commerce cfent 122 then invokes the method indmated 
in the MIME message on the consumer computer 102 in the same manner performed by the commerce server 130 
on the merchant computer 20Z 

Thus, using HTTP POST messages and MIME messages, function caib are placed on the merchant computer 
202 by the consumer computer 102 and function caDs are placed on the consumer computer 102 by the merchant 
computer 20Z Advantageously, WFCP b not tied to any specific function or set of functions. Thus, new cfient-side 
and server-»de functions can be added (and embedded within HTML documents) without modification to the existing 
function-caffing components. The WFCP protocol is described in further detai in a copending patent application 
entitled SYSTEM AND METHOD FOR MAKING FUNCTION CALLS OVER A DISTRIBUTED NETWORK, ffled June 28, 
1996, which is hereby incorporated by reference, in its entirety. 

A further advantage, however, is gained in providing the Web browser 120 with a method to invoke tocal 
functions on the consumer computer 101 Using the same HTTP POST message format, the Web browser 120 
invokes local functions by specifying a URL address that resohfes to a local port. Rather than addressing en HTTP 
POST message to a ronote site on the Web by using a URL similar to *http:/fwww.sporting_goods.com', the Web 
browser 120 directs the HTTP POST to the beat consumer computer 102 by using the URL '127.0.0.1:100* (note 
that "ilOO" spedfies local port 100). This method of directing an HTTP POST message to the local computer is 
facilitated by the local host service of the TCP/IP protocol stack. The URL '127.0.0.1' is a local bop-back address 
recognized by the local host service as identifying the local machine as the recipient of the message. 

A port listener process operates on the local machine 102 monitoring a designated port such as, for 
example, port 100. The port listener receives the HTTP POST message, parses the content, and passes function- 
calling data directly to the commerce client 122. Thus, tocal functions are invoked by selected options coded in and 
hosted by a Web document wherein f unction-caD'mg information is associated with the selected options. This method 
for making local function calls from a Web browser is described in further detail in a copending patent appficatbn 
entitkid SYSTEM AND METHOD FOR MAKING FUNCTION CALLS FROM A WEB BROWSER TO A LOCAL 
APPLICATION, fited June 28, 1996, which is hereby incorporated by reference in its entirety. 
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It wtl be appreciated by those skflled in the art that specialized cfont and server processes provide 
substantial benefits in the context of computer-based shopping. For example, a merchant can conveniently store 
relatively static catalog information as HTML documents, while storing relatively dynamic product information (such 
as price and mventory) in a separate database (not shown in Figure 2) which b accessed by the commerce server 
5 130. Tha product information may advantageously be stored and served in a format which is recognized only by 
the speciafized commerce cGent 122 (as opposed to the standard Web browser 120). Because the commerce client 
122 runs in conjunction with the Web browser 120, the commerce client 122 can readily store both consumer* 
selected HTML (catalog) data from Web pages of merchanu, and the associated non-HTML product ^formation 
retrbved via cfent-to-sarver function caOs. 

10 As noted above, because al information n passed via HTTP, the commerce cGent 122 and conunerce server 

130 can advantageously communicate through Internet firewalls 214 which are typically configured to permit tha 
passage of TCP/IP messages addressed to port 80 and which, for security reasons, are configured to block 
communications addressed to other ports. 

Although Figure 2 depicts a s'uigb Web server 128 interacting with a single commerce server 130, it wQI 

15 be recognized that other system configurations are possflile. For example, multiple Web servers 128 could be 
provided (running on the same machine or on different machines) which interact with a single, shared conunerce 
server 130; or, multiple commerce servers 130 could be provided which interact with a single Web server 128. 
D. Software ArchHectute of Merchant Wd> Site 

Figure 3 ilhistrates a preferred architecture of a merchant Web site 302 of the computer-based shopping 

20 system. As shown fai Figure 3, the merchant Web site 302 mchides a merchant computer 202, a storage device 304 
(corresponding in function to the storage devure 144 of Figure 2), and an Intmet connection 306. Software 
operating on the merchant computer 202 inchides a Web server 128, the commerce server 130, and a method 
Kbrary 308 (corresponding to the method Ebrary 210 of Rgure 2). A collection of Wd) documents 310 is stored on 
the storage device 304 as are various merchant databases 31Z 

25 The merchant Web site 302 may. for example, be a stand alone site which independently serves information 

with respect to a smgle merchant or may be in the form of (or a part of) a centrafized or distributed electronic mall 
system which serves the information of many different merchants. The Web server 128 is preferably tha Microsoft 
Internet Information Server version 1.0, although other conventional Web servers can be used. The commerce server 
130 is preferably in the form of an ISAPI (Intemet Server AppGcation Program Interface) DLL (dynamic Enk library) 

30 which runs within the same process space as the Web server 128. A CGI script, or a DLL which uses another server 
extension API (such as NSAPI from Netscape), could alteroathrely be used. 
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The Web documents 310 stored on the merchant Web site 302 are preferably coded using HTML The Web 
documents 310 contain HTML coding which, when received by a Web Browser 120, display various icons or buttons 
on the screen 114 of the consumer computer 102 along with text or pictures comprising the content of the Web 
document As descrbed above, these icons or buttons comprise selectabta options which correspond to shopping- 
related transactions. In the preferred embodiment the Web documents 310 offer consumers options to add product 
information to an electronic shopping basket view products cotected but not yet purchased, view products already 
purchased, enter payment information into an electrons wallet place shipping addresses in an electronic address 
book, as weB as order goods from Web-based merchants. These selectable optbns coded into the Web documents 
310 have functbn-caing information associated with them (as described above) to invoke executable functions on 
the consumer computer 102 or back on the Web server 128 when selected. Web documents with embedded client- 
side function caBs are also preferably stored on the hard disk of the consumer computer 102 as part of the user 
mterface of the commerce cient 130, albwng the user to invoke cGent side functnns (such as viewing the shopping 
basket) while off -fine. 

The method Gbrary 308 of the merchant Web site includes methods for perfomnng cHent services such as 
retrnval of product information, calculation of sabs taxes, and capture of orders. Some of these nmthods are Bsted 
and described in Tabb 1. 



Method 


Description | 


GetLineltem 


Retrieves product information given SKU (stock keeping unit) 
number or other product identifi^. 


GetPrice 


Retrieves price information given SKU number or other product 
identifier. 


CalculateSH 


Calculates shipping and handling costs given product/s and 
shipping logistics (e.g., shipping address and method). 


CaiculateTaxDue 


Calculates shipping and handling costs given product/s and 
shipping logistics 


ProcessOrder 


Captures order sulnnitted by consumer, and processes in a maimer 
specified by merchant 



TABLE 1 

The commerce server 130 perfonns two primary tasks. First, when a request is received for product 
mformatbn (vb function-calling mformation embedded within an HTTP POST message received by the Web server 
128), the conunerce server retrieves various data items in connection with a product, such as SKU (stock keeping 
unit) number, product name, product descrqition, logo, price, expiration date, tax, and shipping charges. This data 
is packaged as a MIME file of type "x-ishopper* and sent back to the consumer computer 102 via the Web browser 
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120, as descrfted above. Second, the commerce server 130 captures and processes orders for products submitted 
by consumers. 

In accordance with the present invention, the merchant sites of the system prepare and serve HTML Web 
documents 310 which present uniform transaction options, such as View Shopping Basket Show Wallet and Initiate 



Due to the wide variety of inventory management systems and legacy (long-existing and difficult to change) 
product information databases, as well as accounts recehrable systems, the conmierce server will often comprise 
custom interface software that wil change from merchant to nffirchant The present mvention is primarily concerned 
with the consumer platform. 



Rgure 4 Shistrates the software architecture of the consumer computer 102. The architecture comprises 
a conventional Web browser 120 (such as Microsoft's Internet Explorer 10, or Netscape Nav'^ator 2.0), the 
commerce cGent 122, and a conrunerce client ob^ct Ebrary 402, and a storage area 1 12. The commerce cfent object 
Gbrary 402 comprises a shoppmg basket object 404 having assodated shopping basket methods 406, a wallet object 

1 5 408 having associated walet methods 41 0, and an address book object 412 havmg associated address book methods 
414. The storage area 112 comprises merchant information 416, product informatbn 418, payment source data 140, 
and shipping address data 142, aD of which has been selecthrely stored and/or manuaOy entered by the user. 

The Web browser 120 is preferably configured such that the commerce cGent 122 is a MIME4iandler 
app&cation. Generafly, a MIME-handler is a software application designed to provide speciaEzed processing of specific 

20 types of ffles received over the Internet by a Web browser 120. The Web browser 120 of the present invention 
b configured to associate the MIME type "x-ishopper" with a certain ffle name extension such as "ish." When the 
Web browser 120 receives a file of type "x-lshopper," the Web browser wiQ cause the commerce cBent 122 
eppEcation to begin executing Cff not afavady runnkig). The Web browser 120 wiH then pass the received "x-ishopper" 
fOe to the commerce cGent 122 for further processing. Extend'mg the functionality of a Web browser by configuring 

25 the Web browser to associate specific file types with file name extensions and then associating speciafized MIME- 
handler applications with fOe name extensions is well known and will not be further discussed herein. 

The commerce client 122 executes on the consumer computer 102 as a separate process from the Web 
browser 120 and is a standard executable program. The commerce client 122 begins executing when launched by 
the Web browser 120 upon the Web browser's receipt of a file of MIME type "x-ishopper." Another way in which 

30 the commerce client 122 begins executing is when a total port listener task recehres a message from the Web 
browser 120 which was directed at a local port. The port Gstener launches the commerce client 122 if it is not 
already executing. 

StSI another way of launching the commerce cEent 1 22 is by running the commerce client program directly. 
As explained betow in more detail many functions ("locar functions) of the commerce client 122 do not require an 
35 bitemet connection or transmtsston of data to or from a Web »te. These local functions are avaflable via user- 
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interfacs HTML documants which residd on the consumer computer's hard disk. The commerce client 122 executes 
unta the consumer selects an option causing the commerce cGent 122 to stop executing. 

When the connnerce cient 122 starts running, it performs an initial task of loading structures in memorY 
from data stored on the bard dek or other fued storage media. The data represent merchant information, product 
inf onnation, payment source infonnation, and shipping addresses. The data are stored in such a way as to be easBy 
read mto memory whie maintaining relatmnships (finks) among the data. Such construction of ntertnked in-memory 
structures from data stored on a hard disk is wel known in the art. When the commerce cEent 122 shuts down 
or otherwise terminates normally, it writes the interfinked tn-memory structures to hard disk storage in a manner that 
preserves aB the relationships among the data. 

The data comprising the tn-memory data structures are accessed and manipulated through ob^cts. The 
shopping basket object 404 is associated with shopping basket methods 406 which read, write, modify, and display 
mf ormation about merchants and/or products of interest to the consumer. The shopping basket methods 408 interact 
primarBy with in-men)ory structures comprising product and merchant Informatten. In accordance with the present 
invention, data for each product are preferably organized into groups as shown in Table Z 



Pmfliirf Hat a FkiM 


Description 


Logo 


Picture associated with product 
TvDfi- VOID* 


LogoSize 


Size of Picture associated with product 
Type: DWORD 


Name 


Name of product. 
Type: Cstring 


Description 


Description of product 
Type: Cstring 


Price 


Unit Price of product. 
Type: Currency 


Quantity 


Quantity of product to order. 
Type: Float 


ExpirationDate 


Date on which offered price expires. 
Type: Cstring 


Tax 


Amount of tax computed for sale of product. 
Type: Currency 


ShippingCharge 


Cost to ship product as ordered. 
Type: Currency 
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Product Data Held 


Description 


OtherCharges 


Miscellaneous additional charges associated. with order. 
Type: Currency 


SKU 


Stock Keepmg Unit merchant's identifier for product 
Type: Cstring 


Shq)Method 


Delivery services to be used in shipping product 
Type: Cstring 


OrderURL 


URL string identifying Web site to send order for product 
Type: Cstring 


ReferenceURL 


URL string identifying Web site for infonnation about the product 
Type: Cstring 


PaymentFriendlyNanie 


Reference to entry in Payment Database identifying source of payment if 
product b ordered (e.g., Visa, Checking Acct., etc.) 
Type: CString 


AddressFriendlyName 


Entry in Shipping Address DB identifying where to ship product 
Type: CString 


Flags 


0 if product has not been purchased; 1 if product has been purchased 
Type: DWORD 



TABLE 2 

There may be a variety of propertms associated with a product which are unique to that product and are 
not associated with other products. Sucti properties are represented in namefvahie pairs in memory and can be 
referenced from an in-memory product structure through an associated painter to a linked list of such properties. 
The property data are organized as shown m Table 3. 



Property Data Field 


Descriptton 


Name 


Name of property 




Type: Cstring 


Value 


Vahie of property 




Type: Variant 


Flags 


Stores various flag values 




Type: DWDRD 



TABLE 3 

Merchant data preferably comprise associated fields as shown in Table 4. 



Merchant Data Field 
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Logo 


Logo associated with merchant. 
Type: VOID* 


Logosize 


Size of logo associated with merchant 
Type: DWORD 


Name 


Name of merchant. 
Type: Cstring 


LineltemList 


Pointer to finked list of product data structures 
Type: Pointer 



TABLE 4 



The wallet object 408 is associated with waOet methods 410 which provide access to payment source data 
(such as credit card numbers and checking account numbers) used for making on-line purchases. Payment source 
data are stored in memory preferably according to associated fields as shown in Table 5. 



Payment Data Field 


Description 


FriendtyName 


Easily remembered and recognized name for payment source 
Type: Cstring 


CardNumber 


Credit card or account number 
Type: Cstring 


ExprationDate 


Date on which credit card expires. 
Type: Cstring 


CustomerName 


Name of card holder or account holder 
Type: Cstring 


IssuingBank 


Name of bank issuing credit card or account 
Type: Cstring 


BillToAddress- 
FriendlyName 


Reference to address database mdicat'mg address to be billed when 
payment source is used to order product. 
Type: Cstring 



TABLES 

The address book object 412 is associated with address book methods 414 which access address 
information for shipping purposes. The address book methods 414 access address data preferably organized as 
shown in Table 6. 



1 Address Data Field 


Description | 


1 FriendlyName 


Easily remembered and recognized name for addresses 1 
Type: Cstring 
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Name 


Nane of person to receive parceb at address 
Type: Cstring 


Addressl 


First text tine of shipping address. 
Type: Cstring 


Address2 


Second text Bne of shqsptng address 
Type: Cstring 


Addres$3 


Third text line of shipping address 
Type: Cstrmg 


City 


Nanie of city of shipping address 
Type: Cstring 


State 


Name of state of shipping address 
Type: Cstring 


Zip 


Zip code of shipping address 
Type: Cstring 


CountTY 


Name of country of shipping address 
Type: Cstring 


Phonel 


First phone number associated with shipping address 
Type: Cstring 


Phone2 


Second phone number associated with sbqiping address 
Type: Cstring 



TabUT 



The shopping basket object 404, wallet object 408, and address book object 412 are preferably 
implemented as tn-process COM (component object modeO compEant objects, implemented as a single DLL (dynamic 
Gnk libraryK The component object model is weDninderstood in the art and w3I not be further discussed. One skOIed 
in the art will, however, appreciate that callable functions with appropriate associated data structures could be used 
in place of the shopping basket object 404, the waDet object 408, and the address book object 412 and their 
respective associated methods 406, 410, 414. 

Figure 5 IDustrates generally the type of data accessed by the primary objects of the commerce cfient A 
shopping basket object 502 accesses and manipulates merchant data structures 504, product data structures 506, 
and product property data structures 508. A wallet object 510 accesses and manipulates payment source data 
structures 51Z An address book object 514 accesses and manipulates address book data structures 516. 

As described above, the commerce client 120 responds to various function-calling information embedded in 
MIME files of type 'x-ishopper* passed from the Web Server 128 through the Web browser 120, and also responds 
to function-calling information recehred indbectly from the Web browser 120 by way of a local port to which the 
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Wab browser directs data meant for the commerce ctent 12Z The function-caOtng information identifies objects and 
methods which the commerce cSent 122 invokes. 

When viewing a Web document 310 which, for example, descrBies a product (hosts an item) and which is 
coded according to the present invention, the standard Web browser displays an ADO ITEM-type option to the 
5 consumer which aDows information about a product to be stored m the electronic shoppbig basket (m computer 
memory, and eventually written to a hard diskl The AOD ITEM option can be selected, for example, when the 
consumer has interest in the product, even if the consumer has not yet decided to purchase the product. The Web 
document 310 w3l also typicaBy inchjde a product form which is displayed on the consumer's computer screen. The 
product form represents a number of attributes whcb can be set by the consumer by filing in vahies. After setting 

10 attributes as desired (e.g., selectmg a size or color for the product), the consumer selects the ADD ITEM option to 
store such 'user preference" attrbutes abng with the information provided by the merchant 

Figure 6 iDustrates the steps performed when a consumer selects the AOD ITEM option. In a fffst step 
602 the Web browser 120 issues an HTTP POST message to the Web server 128 indicating that a consumer has 
selected an AOD ITEM optuin. In a next step 604, the Web server 128 retrieves product information from the 

15 mwchant web site and sends the mformation to the Web browse 120 as a MIME message of type "x-ishopper." 
Next, m a step 806, the Web browser 120, after estabHshing receipt of a MIME message of type x-ishopper, 
launches the commerce cfient 122 fif it is not already running). The commerce cfient in a step 608, constructs an 
in^emory representation of merdiant product payment and address data read from a hard disk. Then, in a step 
610, the Web browser 120 passes the MIME message to the commerce cHent 122. 

20 The commerce cient 122 uses function-caing information embedded in the passed MIME message to caH 

a method AddUneltem. In the step 612, the AddLmeltem method navigates memory structures (constructed in step 
608) looking for a merchant data structure with a name fnid matching the merchant name passed with the MIME 
message. If no such merchant structure is found m the step 612. then a new merchant structure is appended to 
the Enked Gst of merchants by allocating memory and the new merchant structure is populated with merchant data 

25 from the passed MIME message. The AddLineltem method then, in a next step 614, nav'^ates a Imked Gst of 
product data structures associated with the merchant structure (either found or created in the step 612). Each 
product data structure in the Gst represents one product offered for sale by e merchant In the step 616, the 
AddLineltem method allocates memory for a new product data structure and populates it with data packaged in the 
MIME message such as product SKU, price, quantity, description, name, logo, color, or size. The AddUneltem method 

30 then links the new product data structure to the end of the Gnked product data structures for the merchant. 

In a step 618, the commerce cGent 122 invokes a SetltemProperty method wherein the linked Gst of 
merchant structures is again navigated until a merchant structure having a merchant name matchmg the passed 
merchant name is found. In a step 620, the product data structures referenced by the merchant structure are 
navigated until a product data structure is found having an SKU field equivalent to the SKU number passed in the 

35 MIME message. Then, in the step 62Z the SetltemProperty method navigates a linked Gst of properties referenced 
by the product data structure found, and does so for each property passed in the MIME message. When a property 




wo 98/21679 PCTAJS97/20624 

-22- 

stnicture is found whose name matches the passed property name, the vahie associated with the matched property 
name is replaced with a vahie passed in connection with the property name. In each case where the property Gst 
b navigated and no matchng property name is found, the SetltemProperty method appends a new property data 
structure to the Gnked Ost of properties. The SetltemProperty method allocates memory for the new property data 
5 structure and fills in the name and value and flag fields as appropriate from the data in the passed MIME message. 

In a step 624, the commerce client 122 then executes the steps comprising the VIEW SHOPPING BASKET 
option described below. Thus, when the steps comprismg the ADD ITEM option are completed, a new product data 
structure is stored m memory comprismg data fields such as SKU, price, quantity, picture, description, reference URL« 
and merchant mformation. Also, any special properties assodated with the product such as size, color, or fmish, 

10 are also stored with the new product data structure. As explamed below, default payment source infonnation and 
default sh^pmg address information are also associated with a new product data structure. 

Web documents 310 served by Merchant Web sites and/or stored bcaDy on the consumer computer 102 
offer consumers a selectable optran called VIEW SHOPPING BASKET, This option aOows consumers to retrieve a 
Gst of ail the products that have been placed inside the electronic shopping basket using the ADD ITEM optwa 

15 Figure 7 Ohjstrates the steps in carrying out the VIEW SHOPPING BASKET option. In a first step 702, the 

consumer selects the VIEW SHOPPING BASKET option from withai the Web browser. In a next step 704, the Web 
browser 120 issues a local function cal Then, in a step 706, the commerce cEent 122 is launched Cf not already 
executing) by a local port monitor detecting the local functkin call Next, in a step 708, the commerce cGent 122 
loads the shopping basket COM object in a next step 710, a variable CheckRag is set equal to 0. Then, in a step 

20 712, a toop is entered and is executed once for each merchant data structure. 

In a step 714, the commerce client 122 mvokes a GetHrstltem method. In the step 714, the GetFu^ltem 
method navigates to a ghren merchant In thb first iteration of the loop, the given merchant will simply be the first 
merchant in the merchant data structure Gst. In the step 716, the Gnked Gst of product data structures referenced 
from the fnrst merchant data structure n navigated to the first product data structure. If, m the step 718, it is 

25 determined that there are no product data structures for this merchant or the navigatiDn of the product data 
structure Gst has reached the end of the list then, in a step 720, the GetHrstltem method returns a value of 0. 
If in the step 718 it is determined that another product data structure exists and that the end of the product data 
structure Gst has not yet been reached, then the flag field of the product data structure is compared against the 
CheckFlag variable. Because CheckFlag is equal to 0, the product flag b being compared against the vahie 0 whkh 

30 would mdicate that the product has not yet been purchased. If in the step 722, it is determined that the product 
flag is not equal to the CheckFlag then processing reverts back to the step 716 to check the next product data 
structure in the Gst If, however, in the step 722, the product flag is equal to the CheckHag, indicating that the 
product has not yet been purchased, then in a step 724, a pointer is returned pointing to the product data structure 
of the product that has not been purchased and the name of the product that has not been purchased is added to 

35 a Gst box structure. Next in e step 726 the pointer to the product data structure is saved and iterations of the 
loop are terminated. 
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In the step 728, the GetNexthem method is invoked which begins by nav^ating to a given merchant In 
the step 730, a current chan of finked product data structures b nav^ated to a point equal to a saved pointer 
location (the pointer location saved in step 726 if thb invocation of GetNextltem immediately foOows the tennination 
of the GetFrstltem method, otherwise the pointer location saved in the step 742 is used). Next in the step 732, 
5 the next product data structure in the finked fist is examined. If ki the step 734 it is determined that the end of 
the product data structure Gst has be^ reached then in the step 736, a 0 is retumel If, however, in the step 734 
ft is determined that the end of the product data structure fist has not yet been reached then, in the step 738, the 
product flag b compared aganst the CheckRag. tf m the step 738 the product flag is not equal to the CheckFlag 
then processing resumes in the step 732 examin'mg the next product data structure in the Gst tf , however, in the 

10 step 738 the product flat is equal to the CheckFlag then, in the step 740, a pointer is returned to the product data 
structure and the name of the product is added to the fist box structure. Next in^the step 742, a pointer to the 
product data structure is saved. The GetNextltem method is then invoked again beginning at step 728 where the 
fist of merchant data structures is navigated to the current merchant and the steps 728 through 742 are repeated 
unt9 the end of the merchant data structure is reached. 

15 When, m a step 744, the end of the merchant data structure fist is reached, then In a step 746 a scroOabla 

fist of product names appears on the consumer's computer screen. Tlie fist of product names corresponds to all 
products currently in the electronic shopping basket which have not yet been purchased. 

Web documents 310 also offer consumers a VIEW HISTORY option. By selectmg VIEW HISTORY, a fist 
of product names is displayed on the user computer, al of which have been purchased. In one embodiment the 

20 steps ffiustrated in Figure 7 m relation to the VIEW SHOPPING BASKET option are aQ performed in relation to the 
VIEW HISTORY optbn with one exception. In perfommig the VIEW HISTORY option, the CheckFlag variable m the . 
step 710 is set equal to 1 mstead of 0. Thus modified, the steps detect aQ product data structures whose flags 
are set to 1 tndicatkig that they have already been purchased. The steps of Rgure 7 then construct a fist of product 
names reflecting aO of the products that have been purchased. 

25 In another embodiment selecting the VIEW HISTORY option causes a Est of aD product orders to be 

displayed. Each merchant structure has a reference pointer to a fist of order structures. Each order structure, in 
addition to having f iekis for payment shipping, and order tracking information, also has a reference pointer to a Gst 
of product structures. Thus, the finked fist of merchants is traversed. For each merchant, the respective merchant's 
fist of order structures is traversed. One display item is generated from each order structure. Each display item 

30 shows on the screen of the user computer, the purchase date, the payment information, the shipping address, the 
order tracking identifier, and the products ordered. Note, the products ordered are determined by traversing the 
linked list of product structures associated with each order structure. The VIEW HISTORY option advantageously 
aDows consumers to examine past purchases whether such purchases occurred very recently or many years ago. 
The VIEW SHOPnNG BASKET and VIEW HISTORY options do not require a connection to tite Internet to 

35 operate. In addition, these functions can optionally be invoked without using the Web browser. To perform these 
functions without a Web browser 120, the consumer initiates execution of the commerce cGent 122 by, for example, 
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using a mouse and doubb-cBcking an icon present on a graphical user interface of the consumer computer 102 (an 
icon with which the commerce cfent 122 executable program is associated). A commerce cEent user mterface offers 
consumers a selection of options which do not require a connection to the Internet Tligse options are noted below 
to distinguish them from options which require Web-based communication. 
5 Web documents 310 of the system may also host a DELETE ITEM option to remove an item from the 

electronic shopping basket Figure 8 iBustrates the steps performed to carry out the DELETE ITEM option. In a first 
step 802, the consumer selects the VIEW SHOPPING BASKET option and is presented with a fist of products whkh 
have been gathered but which have not been purchased. The DELETE ITEM option is then presented. 

In a next step, 804, the consumer selects a product name from the fist Then, m a step 806, the consumer 

10 either selects the DELETE ITEM button or presses the delete key of the keyboard. The consumer is then prompted 
to confirm the deletion oi a step 808. If the consumer does not confirm the deletbn in the step 808, then, in a 
step 810, the steps of Ftgure 8 terminate. K, however, in the step 808, the consumer does confirm the deletion, 
then the DeleteLineltem method is invoked. 

A next step 812 then uses a pointer to the product data structure of the selected product to locate the 

15 preceding product data structure in a finked fist. Locating a preceding structure in finked fist is preferably done by 
knplementing the fist as a double finked ist (one whose structures point both to the next structure as well as the 
preceding structure). It s possSib that thm b no preced'mg product data structure, that b, that the product data 
structure for the selected product b the first bi the tst of such product data structures that b referenced by a 
merchant data structure. In any case, a pomter to the product data structure will be located, it will simply belong 

20 to a merchant data structure rather than to a preceding product data structure. 

In a step 814, the same pointer to the, product data structure of the selected product b used , to locate a 

following product data structure (Le., one which foHows the product data structure correspondhg to the selected 
product). It b poss3)le that there b no foOowmg product data structure or, in other words, the product data 
structure of the selected product has a NULL pointer to the next product data structure. 

25 Fnany, in a step 816, the pointer tocated in the step 812 p-e^ the pointer which points to the product data 

structure of the selected product) b set to point to the product data structure which follows the product data 
structure of the selected product In the case where there b no product data structure following the product data 
structure of the selected product then the pointer located in the step 812 b simply set to NULL Thus, the product 
data structure of the selected product b no tonger referenced (b definked) from the in-memory data structures and 

30 b effectivety deleted. The DELETE ITEM option b offered to consumers via the commerce cfient user interface as 
weD as on Web documents displayed by the Web browser 120. 

Another option that b presented to a consumer f oHowing selectbn of the VIEW SHOPPING BASKET option, 
b an option to SEE ITEM DETAILS. The SEE ITEM DETAILS option allows a consumer to check the value of the 
unique properties of a product (e.g., a selected color or size) as well as the payment source to be used in connection 

35 with a purchase and also the address the product b to be shipped to if ordered. 
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Hgure 9 illustrates the steps perfonned in relation to the SEE ITEM DETAILS option. Hrst, in a step 902, 
the consumer selects the VIEW SHOPPING BASKET bunon and is presented with a Gst of products. In a next step, 
904, the consumer, selects a product name from the Est Then« in a step 906, the consumer selects the SEE ITEM 
DETAILS button. 

5 The Web browser 120 then, in a step 908, sends a local HTTP POST message directed to a local port 

A port listener responds to the message in a step 910, and forwards the message to the commerce client 122 in 
a step 911 

in a step 914, the commerce client 122 uses a pointer to the product data structure of the selected 
product (this pointer b maintained foDowtng the selection of the product ki connection with the VIEW SHOPPING 

10 BASKET option) to conveniently locate the product data structure of the product selected. Next in a step 916, a 
drop-down box is created having the Friendly Name of a payment source fte., the value associated with the 
PaymentFriendlyName f»ld of the product data structure) as the only entry. Similarly, m a step 918, a second drop- 
down box is created having the Friendly Name of a shipping address O-e., the value associated with the 
AddressFriendlyName field of the product data structure) as the only entry. 

15 A method GetFtrstProperty 922 b then invoked and, in a step 920, the GetFirstProperty method, examining 

the contents of a property Gst pointer associated with the product data structure of the selected product locates 
the First property data structure in a Gnked Gst of property data structures referenced by the product data structure. 

Next a method GetNextProperty 924 b repeatedly called in a step 926 to navigate the Gnked Gst of 
20 property data structures. In a step 928, a Gst box b created having an entry for each property name / property 

vahie pair encountered in navigating the Gnked Gst of property data structures. 

In a step 930, a GetPaymentRrstFriendlyName method 932 b invoked to examine the root pointer to the 
Gnked payment source structures and to return the vahie of the Friendly Name of the first payment source structure. 
A Friendly Name, as discussed behiw, b simply a name fike '^ob's Vba CanT which b conveniently used to 
25 designate a payment source. In the step 934, the GetPaymentNextFriendlyName method 936 b used to navigate 
the Gnked Gst of payment source structures, placing the Friendly Name of each in the drop-down box already created 
in the step 916. 

In a next step 938, a GetAddressFtrstFriendlyName method 940 b mvoked to examine the root pointer to 
the Imked shipping address structures and to return the vahie of the Friendly Name of the first shipping address 
30 structure. A Friendly Name, as used with respect to an address, b a name Gke *the office' or 'Debbie's house' 
which is conveniently used to designate a shipping address. In the step 942, the GetAddressNextFriendlyName 
method 944 b used to navigate the Gnked Gst of shipping address structures, placing the Friendly Name of each in 
the drop-down box already created in the step 918. 

Thus, a consumer can browse a Gst (dbplayed on the consumer's computer 102 screen as a scroOable Gst 
35 box) of aU properties and their corresponding vahies associated with the selected product and can modify the 
property vahies if desired. Abo, the consumer can select from either of the two dropdown boxes dbplayed on the 
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consumer computer 102 to change the payment source to be used to purchase the product or to change the shipping 
address for delivery of the product if purchased. 

bi a step 846, a choice box is displayed to the consumer offering the choices OK or CANCEL If, in the 
step 948, it is determmed that the consumer selected CANCEL then, in a step 950, the Bst boi and the two drop- 
5 down boxes are cleared from the consumer computer and the steps of Figure 9 terminate. If, however, in the step 
948, the consumer selected OK, then, in a step 952, a SetltemProperty method 954 is invoked to replace the values 
of the properties modified by the consumer, as weS as to replace the Friendly Name for payment source or shipping 
address if either was changed by the consumer. The SS ITEM DETAILS option b present on the commerce cBent 
user interface as well as on Web documents. 

10 To manage payment source infonnation, the present invention also allows a consumer to view and modify 

the contents of an electronic waltet A Web document hosts (provides to a consumer) the option VIEW WALLET and 
mctades embedded f unction-calEng information which invokes wallet-related functions. It wiQ be understood that the 
Web browser 120 generates a HTTP POST message directed to the local consumer computer 102, and that a port 
Estener process receives the message and passes it to the commerce client 122 and also launches (executes) the 

15 commerce cEent if necessary. 

Figure 10 iBustrates the steps performed in connection with viewing and manipulating payment source data. 
In a first step 1002, the consumer selects the VIEW WALLET option. Next, in a step 1004, the commerce client 
122, having received the function-calling information from the port Estener, loads the wallet object bi a step 1006, 
the GetPaymentRrstFrtendiyName method 1008 b invoked to examine a maintained root po'mter (a pointer to the first 

20 in a linked fist of payment source data structures) to determine the value of the Friendly Name associated with the 
first payment source data structure. This fffst Friendly Name b used as the first entry in a fist box. Next, in a step 
1010, the GetPaymentNextFriendty Name method 1012 b mvoked to traverse the finked fist of payment source data 
structures and place the Friendly Name assocbted with each as an entry in the tist box. 

in the step 1014, a browsable Est box b dbplayed to the consumer, fisting aE Friendly Names assigned to 

25 payment sources. In a next step 1016, optnns to ADD, EDIT, DELETE payment sources are presented to the 
consumer, as b an option to MAKE PREFERRED (estabEsh as the defauh) one of the payment sources. 

If, in the step 1016, the consumer selects the ADD payment source option, then, in a step 1018, a diahig 
box b displayed with blank or mcomplete fields corresponding to payment source information. The fields are designed 
to oEcit infomfiation such as credit card number, bsuing bank, expiration date, name on card. Friendly Name, and 

30 biOing address. The consumer can enter information corresponding to a credit card, debit card, or any other cash 
substitute. Then, in a step 1020, the consumer filb in the fields and, if the consumer desires to retain the entered 
information in the electronic wallet, the user b prompted to enter a password twbe for verification in a step 102Z 
When tite passwords are typed conrectiy twice, then in a step 1024, the password b used to encrypt the entered 
payment source data, and the encrypted data b stored in association with the Friendly Name entered by the 

35 consumer which b not encrypted. The consumer can then exit from viewing the waOet or continue with further 
manqiulatbns of payment source data. 
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If, m the st^ 1016, the consumer selects EDIT payment source data, than upon selecting a Friendly Name 
correspondkig to payment source data, the consumer, in a step 1026 is prompted to enter a password. If the 
password b conrect it is used to decrypt the encrypted payment source information associated with the selected 
Frtendly Name, bi a step 1028, the decrypted payment source information is presented to the consumer m a dialog 
5 box. The data are broken into fields for consumer editmg. 

In the step 1030, the consumer modifies the data fields. When the consumer is finished updating payment 
source information, the consumer, in a step 1032, is prompted to enter a password twice. This password may be 
different from the password entered earlier to access the payment source data. When the password is successf uBy 
entered, the updated payment source data is encrypted and stored in association with the Friendly Name (which b 

10 not encrypted). Password protectbn at the consumer computer 102 tevel is an advantage of the present invention 
which ensures that only one person has access to credit card numbers and other financial information. 

In the step 1016, the consumer may elect to DELETE payment source data. Upon selectmg from the Est 
box of step 1014 a Frmndiy Name correspondbig to payment source data to be deteted and also selecting the 
DELETE payment source option, the consumer is asked, in a step 1036, to confirm the deletion request If the 

15 consumer confirms the deletion, then payment source data associated with the selected Friendly Name is removed 
from the linked fist of payment source data structures. It wiB be appreciated by those skited in the art that a 
password prompt can be added to the deletion steps to protect against undes'ved deletions. 

The step 1016 also offers the option to MAKE PREFERRED one of the payment sources. Making a 
payment source preferred causes iu Friendly Name to be associated by default with product information that is 

20 added to the etectronic shopping basket Generally, a preferred payment source would be an often used credit card 
account perhaps offering a very^competitive interest rate or earning for the cardholder airl'me frequent flyer mOas 
whenever money is spent If the consumer, in the step 1016, selects a Friendly Name from the fist box of step 
1014, and then selects MAKE PREFERRED, the Friendly Name selected becomes, in the step 1040, associated with 
the default payment source. One of ordinary skiB wffl understand that a confirmatkin check could be added to the 

25 MAKE PREFERRED steps to avoid unmtended replacements of a prior default payment source. When the consumer 
is finished viewing and manipulating payment source data, the user terminates the VIEW WALLET options and screen 
display by selecting an EXIT (or similarly labeled) button. 

Very similar to the manner m which the present invention faciEtates viewing and manipulating payment 
source data in the electronic waDet is the manner in which it permits consumers to view and manipulate shipping 

30 address data in the electronic address book. Figure 1 1 iflustrates the steps in viewkig or manipulating address book 
data. In a first step 1102, the consumer selects a VIEW ADDRESS BOOK option. In a next step 1104, the 
commerce cGent 122 loads the address book object 

In a step 1106, the GetAddressFirstFriendlyName method 1108 uses a main tamed root pointer (always 
points to the first of a linked Est of shipping eddress data structures) to examine the first shipping address data 

35 structure and to return the associated Friendly Name. A Friendly Name for a shipping address might be, for example, 
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'My Castb/ or 'JOTs Office.' The Friendly Name associated with the first shipping address data structure » used 

as the first entry in a browsabia ist box. 

Next, in a step 1110, the GetAddressNextFriendlyName method 1112. is used to traverse the Enked Est 

of shipping address data structures and to mchide the Friendly Name associated with each structure in the Est box 
5 created in step 11 OB. The Est box is displayed to the consumer m step 1114. A step 1116 presents options to 

the consumer to ADD, EDIT, DELETE shipping address data, as well as to MAKE PREFERRED a shipping address. 
If, in the step 1116, the consumer elects to ADD shipping address data, then, in a step 1118, a dialog box 

is displayed to the consunmr containing blank or mcompbte fields corresponding to shipping address data such as 

street address, city, state, country, zip code, name, and Friendly Name. In a next step 1120, the consumer enters 
10 information into the fields. When the consumer b satisfied that the informatran is complete and accurate, the 

consumer selects the OK button in the step 1122, and the new shaping address is saved in association with the 

new Friendly Name entered. 

As with the electronk: waBet, the consumer can also elect to EDIT data in the electronic address book. 

Because there is not as much need for security, there is no password access to or encrypting performed on the 
15 shipping address data. One sVSki in the art win understand that password-protected access could be imptemented 

in connection with the shipping address data as specified with respect to the payment source data. If the consumer 

elects to EDIT shqiping address data, then, after selecting a Friendly Name from the browsabia Est displayed in the 

step 1114, a dialog box is displayed in a step 1124 presenting fielded data items corresponding to the existing data 

associated with the selected Friendly Name. In the step 1126, the consumer modifies the existing shaping address 
20 data. When satisfied that the changes are complete, the consumer selects an OK button *m a step 1 128 which saves 

the changed sh^p'mg address information m association with the Friendly Name (which may have just be^n phanged 

by the user). 

If, in the step 1116, the consumer elects to DELETE shipping address data, then, after selecting a Friendly 
Name corresponding to a shipping address, the user is prompted in a step 1130 to confimi the delete request If 
25 the consumer confirms the delete request in the step 1 130, then in a step 1132 the shipping address data is deleted 
along with the Friendly Name. 

If the option to MAKE PREFERRED a shipping address is selected in the step 1116, then, in a step 1134 
the shipping address data associated with the selected Friendly Name b associated with the default shipping address. 
Thereafter, any products placed into the electronic shopping basket wiD acquire automatically, by default, an 
30 association with the new shqiping address. One skiBed in the art w3l appreciate that a confirmation step such as 
that in step 1130 with respect to deleting shipping address data could be added to safeguard against unintended 
modifications to the default shipping address. Note that both the VIEW WALLET and VIEW ADDRESS BOOK options 
are available from the commerce client user interface. 

With payment source information in the electronic wallet and shipping address information in the electronic 
35 address book, the present mvention enables a consumer to purchase products in the electronic shopping basket Web 
documents host a READY TO BUY option. 
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Figure 12 ihistrates the steps of purcha^g a product. In a first step 1202, the consumer selects the 
READY TO BUY option. Next in a step 1204, the shopping basket object is loadel Then, in a step 1208, the 
GetFirstltem method 1208 b used to examma a maintained root pointer to the first merchant data structure and to 
then traverse and examine the Gnked Est of product data structures associated with the first merchant and return 
5 the first located unpurchased product. The Flag of each product data structure is examined to determine if the 
product is already purchased. K no unpurchased products are discovered in association with the first merchant data 
structure, the GetFirstltem moves to the next merchant structure in the linked list of merchants. The GetFirstltem 
method returns information (such as a pomter) idantifymg the first product structure associated vrith an unpurchased 
product encountered m its traversal of the merchant and product structures. 

10 in a next step 1210, the GetNextltem method 1212 is used to complete the traversal of the merchant and 

product structures, returning nformation identifying all product structures associated with unpurchased products. 
In a stqs 1214, a fist of al unpurchased products b generated and b then sorted by merchant and by 
PaymentFriendlyName. Next in a step 1216, the Est of unpurchased products b dbplayed to the consumer, and 
the consumer b prompted to confirm the purchase request. If, h the step 1216, the consumer confirms the 

15 purchase, then the wallet object b loaded in a step 1218. Otherwbe, the steps of Figure 12 are terminated and 
no purchase occurs. 

With the unpurchased product items in the electronk: shopping basket sorted by merchant (e.g. 'LL Bean* 
or 'Sears*), a step 1220 dhrides the product items into groups, one group per merchant A first product group 
associated with a fvst merchant b designated for processing. A step 1222 then dhrides (or sorts) the first group 

20 into further subgroups according to the value of the PaymentFriendlyName (e.g., 'Gold Card" or 'Mary's Amex'l. 

Thus, different orders can be submitted to one merchant but paid for using different payment sources. 

One having ordinary skiD in the art win appreciate that a tha^d subgrouping coukl be performed such as, 
for example, a subgroup'mg based on the vakie of AddressFriendlyName (e.g., 'Grandma's House' or 'Alaska Cabh'). 
Such an additional subgrouping wouU conveniently support orders which could be submitted to one merchant cause 

25 payment from different payment sources and assist the merchant in shipping products to different locatmns. Further, 
products paid for from the same payment source could conveniently be shipped to different addresses. 

Associating a group of products for a single merchant that are to be purchased from a single payment 
source, a GSO (goods and services order) b submitted to the GenerateGSOPi method 1242 on the waDet object 
bi a step 1224, the GenerateGSOPi method 1242 extracts the stored and encrypted data (or blob) associated with 

30 the passed PaymentFriendlyName. in a next step, 1226, the consumer b prompted for a password to authorize 
payment from the payment source associated with the passed PaymentFriendlyName. If the password is incorrect 
the purchase b not authorized and the next subgroup of products b identified whereupon step 1222 repeats. It 
howevet the password b correct, then the encrypted payment source data b decrypted in a step 1228, and a 
payment instruction b formed from the payment source information and the product information. The payment 

35 instruction contains data sufficbnt to allow a merchant to complete the order. In a next step, 1230, the payment 
instruction along with the product Est b passed to an encryption DLL to be encrypted. The encryption DLL uses RSA 
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encryption technology (a form of pubHc/private key encryption) which is known. The present invention is not bnited 
by encryption technotogy, and other forms of encryption couU be used. The GenerateGSOPI method 1242 then 
passes the encrypted order to a step 1232 wherein the order is sent to a merchant's order URL (held as a field 
associated with a product data structure) as part of an HTTP POST message. Thus, the commerce cfient 122 is 
5 able to bypass the Web browser and transmit HTTP POST messages itself. 

After transmitting an order, the commerce cEsnt 122 then updates the in memory structure for the 
respective merchant Each merchant structure includes a reference pointer to a linked Est of order structures. The 
commerce client 122 traverses the inked Est of order structures, if any, to reach the fmal order structure. The 
commerce cGent 122 aBocates memory for a new order structure, foks the new structure to the Est of order 

10 stractures for the merchant, and then populates the new order structure with payment mformation, shipping address 
information, and a pointer to the product stracture associated with the product ordered. An order tracking identifier 
COT!') field of the new order stracture is left blank. One skiDed in the art w9 appreciate tiiat foked Ests of 
stnictures is merely one way of associathg data items together, and that other methods such as relational databases 
can be used to accomplish a sanilar association. 

15 A merchant site receding a product purchase order transmits an order confirmation message to a Web 

browser 120. The order confffmation message transmits an order tracking identifter rOTI") to the Web browser 120. 
The Web browser 120 displays the DTI on the screen of the user computer, along with a message which states, 
for example, Hliank you for your order. If tfiere is any problem, please phone 1 800 123 4567 and be prepared 
to refer to the foUowing order tracking identifier.' The OTI is also embedded in a MIME message of type x-ishopper 

20 which is passed by the Web browser 120 to the commerce cEent 122. The commerce cGent 122 then copies the 
OTI to the blank GTI fieU of the order structure, tiius completing the storage of information related to the purchase, 
A step 1234 determines whether additional products for the current merchant r«nain to be purchased. If 
so, processing resumes at the step 1222, and, if not process'mg resumes upon the next group of products from the 
next merchant at the step 1220. A step 1238 determines whether all products for aD merchants have b^n 

25 purchased. If not then processing resumes witii the step 1220. If all products have been purchased as determined 
by the step 1236, then the Flag field for every product m the electronic shopping basket is marked "purchased" Tte., 
set equal to 1). Finally, in a step 1240, tiie steps comprising tiie VIEW SHOPPING BASKET option and the VIEW 
HISTORY option are invoked to force updates to memory structures and screen displays to avoid confusion as to 
whether any product was m fact purchased. 

30 An ORDER STATUS optkm is presented to a user by the commerce client 122 after selection of the VIEW 

HISTORY option. Once a fist of orders is generated and displayed to the user as described above, the user selects 
an order (preferably by positioning a mouse pointer over information associated with an order and cficking a mouse 
button). The user then selects the ORDER STATUS option. The commerce client then generates an HTTP POST 
message containing the order tracking identifier ('OTI'), and transmits the HTTP POST message to the order URL 

35 (unuiuely identifying the Internet address of the selling merchant) associated with the product (or products) purchased. 
A merchant site receiving an HTTP POST message which includes an OTI determines the status of the order (e.g.. 
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•SHIPPED,' -CANCELED/ TWAmNG FOB INVENTORY/ etc). The merchant site transmits an HTML document to 
the Web browser which includes the status information. The Web browser of the user computer displays the status 
information on the screen of the user computer. 

A consumer recehres on-6na assbtance (or help) in using a computer-based shopping system by selecting 
5 a HELP option. In one embodiment the HELP option is included m the HTML coding of a Web document and 
displayed to the user by a Web browser. Selecting the HELP option causes the Web browser 120 to access a HELP 
Web site. 

In another embodonent, the HELP option is displayed to the user by the user interface of the commerce 
cimnt 12Z Selecting the HELP option in this embodiment ceuses the commerce cBent 122 to estabfish a TCP/IP 

10 communication Onk to another computer if such a Gnk is not already estabBshed. The commerce cBent 122 transmits 
an HTTP POST message directly to a HELP Web site. The commerce cGent 122 causes the Web browser 120 to 
begin running on the user computer if it b not already running. 

In either embodonent of the HELP option, the Web browser dbpbys help information included in documents 
served by a Web server of the HELP Web site. The he(p information, for example, descrOies the use of the computer- 

15 based shopping system or the cause of errors encountered in operatmg the computer-based shopping system, offers 
tips, or Bustrates features of the computer-based shopping system with pictures and diagrams. One skSled m the 
art will appreciate that on-line help couU alternatively be made avaSabte to consumers via a hterarchicaOy ordered 
(topics, subtopics, and sub-subtopics) coDaction of information residing on the consumer computer 102. 

A consumer conveniently accesses a merchant Web site 302 from which product information has been 

20 obtained by selecting the JUMP TO MERCHANT option. The user interface of the commerce client tnchides the 
JUMP TO MERCHANT option. By maintaining an association between a productname and 3 merchant Web site URL 
within the product data structure of every product, a computer-based shoppng system locates a URL associated with 
the merchant seBing a product by accessing the product data structure for the product. The commerce cEent 122 
generates an HTTP POST message accessing the merchant Web site associated with the product The merchant 

25 Web site responds by transmitting an HTML docamtent to the Web browser 120. Thus, the consumer conveniently 
accesses the Web site from which mformation about a product was obtabied. 

A consumer terminates a computer-based shopping system by selecting an EXIT button. The EXIT button 
causes the commerce cGent 122 to write linked in-memory data structures to a hard disk (other storage devices can 
suffice) in a manner which preserves the link relationships. The commerce cOent 122 then stops executing on the 

30 consumer computer 1 02. 

Thb invention may be embodied in other specific forms without departing from the essential characteristics 
as described herein. The embodiments described above are to be considered in all respects as fllustrative only and 
not restrictive in any manner. The scope of the invention b indicated by the foltowing claims rather than by the 
foregoing description. Any and all changes which come within the meaning and range of equivalency of the claims 

35 are to be considered within their scope. 
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In dw daims which follow, alphabetic characten used to designate daim steps are provided for convenience 
of dascriplion only, and are not intended to inipiy any particular order for performing the steps. 
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WHAT IS CLAIMED IS: 

1. A cGent architecture for conducting electronic commerce over the Internet comprising, on a 
conrqiuter-readable medhim: 

a Web browser appfication conf^ured to run on a computer; 
5 a commerce client appEcation configured to run on the computer in conjunction with the Web 

browser applicatbn, the commerce cEent application inchtding a caOabb function, said caBable function 
comprising executabb computer instructbns stored on a computer storage medbm accessibb by the 
computer; 

an ebctronic shopping basket object configured to access and manipubte product mformatton and 
10 merchant information stored on the computer storage medium, the access and manipulatbn initiated by 

executing the caOabb functbn of the commerce cOent application; and 

a Web document which inchides embedded functbn-calGng oiformatbn that corresponds to the 
caBabb function of the commerce cEent appEcatbn, the function-calling information embedded within the 
Web document such that a user can sebctively initiate the execution of the calbbte function whib viewing 
15 the Web document with the Web browser. 

2. A client architecture for conducting electronic commerce over the Internet, 
comprising, on a computer-readable mediimi: 

a Web browser application configured to run on a computer; 
a commerce client application configured to run on the computer in 
20 conjunction with the Web browser application, the commerce client application 

including a callable function; — - 

an electronic shopping basket function configured to store product 
information and merchant information to a computer storage medium accessible by 
the computer, said electronic shopping basket function comprising executable 
25 computer instructions stored on a computer storage medium accessible by the 

computer, the product information and merchant information retrieved from 
merchant Web sites over the Internet via the Web browser, the storing initiated by 
executing the callable function of the cocomerce client ^plication; and 

a Web document which includes embedded function-calling information that 
corresponds to the callable function of the commerce client application, the 
function-calling information embedded within the Web document such that a user 
can selectively initiate the execution of the callable function while viewing the 
Web document with the Web browser. 
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3. A client architecture for conducting electronic commerce over the Internet, 
comprising, on a computer-readable medium: 

a Web browser application configured to run on a computer; 

a commerce client application configured to run on the computer in 
conjunction with the Web browser application, the commerce client application 
including a callable function; 

an electronic shopping basket fimction configured to retrieve product 
information and merchant information fi-om a computer storage medium accessible 
by the computer, said electronic shopping basket function comprising executable 
computer instructions stored on a computer storage medium accessible by the 
computer, the product information and merchant information obtained fiom 
merchant Web sites over the Internet via the Web browser, the retrieval initiated 
by executing the callable function of the commerce client application; and 

a Web document vAAch includes ^bedded function-calling information that 
corresponds to the callable fimction of the commerce client {plication, the 
fimction-calling information embedded within the Web document such that a user 
can selectively initiate the execution of the callable function vAule viewing the 
Web document with the Web browser, 

4. The client architecture according to Claim 1, wherein the conunerce client 
application includes a second callable function, and wherein the Web document includes 
embedded fimction-calling information that corresponds to the second callable function of 
the commerce client application, the execution of the second callable function selectively 
initiated by the user vMlc viewing the Web document with the Web browser, the client 
architecture further comprising, on the computer-readable medium: 

an electronic wallet function configured to access and manipulate payment 
source information stored on the computer storage medium, the access and 
manipulation of the payment source information initiated by executing the second 
callable function of the commerce client ^plication. 

5. The client architecture according to Claim 1, wherein the conunerce client 
application includes a second callable function, and herein the Web docimient includes 
embedded function-calling information that corresponds to the second callable function of 
the commerce client application, the execution of the second callable function selectively 
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initiated by the user ^le viewing the Web document with the Web browser, the client 
architecture further comprising, on the computer-readable mediimi: 

an electronic address book object configured to access and manipulate 
shipping address information stored on the computer storage medium, the access 
and manipulation of the shipping address information performed by executing the 
second callable function of the commerce client application. 

6. A clirat architecture for purchasing products over the Internet, comprising, 
on a computer-readable medium: 

a commerce client application conjBgured to run on a computer, the 
commerce client application configured to transmit information to a World Wide 
Web site in accordance with World Wide Web protocols, the commerce cli^t 
application configured to run in conjunction with a Web browso-, the conunerce 
client application including a product purchase function vMoh combines product 
information, merchant information, and payment source information and transmits 
the combmed information to a World Wide Web site, the product purchase function 
comprising executable computer instructions stored on the computer-readable 
medium. 

7. The client architecture according to Claim 6, further comprising, on the 
computer-readable mediiun: 

a Web browser ^plication corifigured to hin on the corriputer; ismd 
a Web document which includes embedded function-calling information that 
corresponds to the product purchase function of the conunerce client application, 
the function-calling information embedded within the Web document such that the 
user can selectively initiate the execution of the product purchase function vAnle 
viewing the Web document with the Web browser. 

8. The client architecture according to Claim 7, further comprising, on the 
computer-readable mediiun: 

an electronic shopping basket object configured to access and manipulate 
product information and merchant information stored on the computer storage 
medium, the electronic shopping basket function transmitting product information 
and merchant information to the commerce client implication diuing execution of 
the product purchase function of the commerce client application, the electronic 
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shopping basket object comprising executable computer instructions stored on the 
computer-readable mediimi. 

9. The client architecture according to Claim 7, further comprising, on the 
computer readable medium: 

5 an electronic wallet object configured to access and manipulate payment 

source information stored on a computer storage medium accessible by the 
computer, Ae electronic wallet object transmitting payment source information to 
the commerce cUcnt application during execution of the product purchase function 
of the commerce client application, the electronic wallet object comprising 
JO executable computer instructions stored on the computer-readable medium. 

10. A method for gathering product information over a distributed network, 
comprising: 

(a) siding a first hyp^text document over the distributed network to a user 
computer, the first hypertext document comprising (i) a description of a first 

15 product, (ii) a user-selectable product gathering option, and (iii) function-calling 

information associated with the product gathering option; 

(b) displaying the first hypertext document to a user via the user computer 
and monitoring user input for selection of the product gathering option; and 

(c) responding to user selection of the product gathering option by calling 
25 ah executable function specified by the fimctioii-callihg infdimadon, the function 

storing the description of the first product to a local data storage area of the user 
computer. 

11. The method according to Claim 10 vdierein step (a) comprises sending an 
HTML document over the distributed network from a Web server running on a merchant 

25 Web site to a Web browser ruiming on die user computer, the Web server in a location 
remote to the Web browser. 

12. The method according to Claim 10 wherein step (c) further comprises 
passing at least a portion of the fimction-callmg information from a Web browser to a 
local process running on the user computer, the local process calling the function. 

30 13. The method according to Claim 10, further comprising the steps of: 

(d) sendmg a second hypertext document over the distributed network to the 
user computer, the second hypertext document comprising (i) a description of a 
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second product, (ii) a second selectable product gathering option, and (iii) function- 
calling information associated with the second product gathering option; 

(e) displaying the second hypertext document to the user via the user 
computer and monitoring user input for selection of the second product gathering 
option; 

(f) responding to usct selection of the second product gathering option by 
calling a second executable function, the second function storing the desoiption 
of the second product to the local data storage area; 

(g) displaying a product comparison option to the user via the user 
computer and monitoring user input for selection of the product comparison option; 
and 

(h) responding to user selection of the product comparison option by 
retrieving from the local storage area the desc^ption of the first product and the 
description of the second product, and by formatting the descriptions and 
displaying the desoiptions to the user via the user computer. 

14. A method for purchasing a plurality of products fiom a plurality of 
merchants over a distributed network, comprising the steps: 

(a) storing on a computer storage medium a first network address 
corresponding to a first merchant and a second network address corresponding to 

' a second merchiant, the computer storage medium accessible by a xiser computer; 

(b) storing on the computer storage medium a first product identifier 
uniquely identifying a product of the first merchant and a second product identifier 
uniquely identifying a product of the second merchant; 

(c) storing on the computer storage medium payment source data, the 
payment source data rq)resenting a source of credit or a source of funds; 

(d) displaying a product purchase option to a user via the user computer and 
monitoring user input for selection of the product purchase option; 

(e) respionding to selection of the product purchase option by combining the 
first product identifier with the payment source data to generate a first payment 
instruction, and by combining the second product identifier with the payment 
source data to generate a second payment instruction; 

(f) transmitting the first payment instruction fi*om the user computer to the 
first network address over the distributed networic; and 
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(g) transmitting the second payment instruction from the user computer to 
the second network address over the distributed network. 

15. A method according to Claim 14 wherein step (f) comprises encrypting the 
first payment instruction and transmitting the encrypted first payment instruction to the 

5 first network address, and A^erein step (g) comprises encrypting the second payment 
instruction and transmitting the encrypted second payment instruction to the second 
network address. 

16. A method according to Claim 14 A^erein the payment source data of step 
(c) is enoTpted using an encryption password as a key, the encrypted paymmt source data 

10 not humanly readable, and wherein step (e) further comprises prompting the user for entry 
of the encryption password and using the racryption password to decrypt the payment 
source data. 

17. A method for purchasing a plurality of products fix>m a merdiant over a 
distributed network, comprising: 

15 (a) storing on a computer storage medium a network address corresponding 



20 quaiidty of the product and a second quantity value represetiting a second quantity 



to a merchant, the computer storage medium accessible to a user computer; 

(b) storing on the computer storage mediimi a product identifio: uniquely 
identifying a product of the merchant; 

(c) storing on the storage medium a first quantity value representing a first 



of the product; 



25 



(d) storing on the storage medium first and second encrypted payment 
source data, the first and second encrypted payment soiuce data not humanly 
readable, the respective encryptions performed with user-entered first and second 
payment source passwords as encryption keys; 



(e) displaying a product purchase option to a user on the user computer and 
monitoring user input for selection of the product purchase option; 



30 



(f) responding to selection of the product purchase option by prompting the 
user for the first payment source password and the second payment source 
password; 



(g) monitoring user input for entry of the first and second payment source 
passwords; 
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(h) decrypting the first encrypted payment source data using the first 
payment source password and deoypting the second encrypted payment source 
data using the second payment source password; 

(i) combining the product identifier, the first quantity value, and the first 
payment source data to generate a first payment instruction; 

(j) encrypting the first payment instruction to generate a first encrypted 
payment instruction; 

(k) transmitting the first encrypted payment instruction to the networic 
address; 

(1) combining the product identifier, the second quantity value, and the 
second payment soiirce data to generate a second payment instruction; 

(m) encrypting the second payment instruction to generate a second 
encrypted payment instruction; and 

(n) transmitting the second encrypted payment instruction to the network 
address. 

18. A method in accordance with Claim 17 \^erein the first payment instruction 
of step (i) is generated by combining the product idratifier, the first quantity value, the 
first payment source data, and a first shipping address, and wherein the second payment 
instruction of step (1) is generated by combining the product identifier, the second quantity 
value, the second {payment source data, and a second shippiiig address, the tnethod 
comprising the fiirther step of: 

(o) storing on the computer storage mediimi a first shipping address and a 
second shipping address. 

19. A method for using a Web browser to manage local data, the Web browser 
running on a user computer, the local data stored on a computer storage medium 
accessible by the user computer, the method comprising the stepis of: 

(a) receiving with the Web browser an HTML document comprisiag a user- 
selectable view option and function-calling information associated with the view 
option; 

(b) displaying the HTML document and the user-selectable view option to 
a user via the user computer; 

(c) monitoring user input for selection of the view option; and 
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(d) responding to selection of the view option by calling a view function 
specified in the function-calling infonnation, the view, function comprising 
executable computer instructions accessible by the computer, the view function 
accessing and formatting the local data and displaying the local data to the user. 

20. A method according to Claim 19 wherein the calling of the view function 
of step (d) is performed by smding a message which includes at least a portion of the 
function-calling information bom the Web browser to a local Internet address representing 
flie user computer, a local port-monitoring process monitoring the local Internet address 
and receiving the message, the local process using the function-calling information to 
make the function call. 

21. A method according to Claim 19 wdierein the calling of the view function 
of step (d) is performed by sending a message ^ch includes at least a portion of the 
function-calling information fiom the Web browser to a local Internet address representing 
the user computer, a first local process monitoring the local Internet address and receiving 
the mess^e, the first local process invoking a second local process if it is not already 
running, the first local process passing at least the function-calling information to the 
second local process, the second local process using the function-calling information to 
call the view function. 

22. A method according to Claim 19 wherein step (d) comprises responding to 
selection of the view option by calling a view function rqiresented in the fiinctibri-calling 
information, the view function accessing and formatting the local data and displaying the 
local data to the user, and the view function also displaying an add option to the user, the 
method further comprising the steps of: 

(e) monitoring user input for selection of the add option; 

(f) responding to selection of the add option by prompting the user to enter 
additional local data; 

(g) monitoring user input for entry of additional local data; and 

(h) responding to entry of additional local data by storing the additional 
local data on the computer storage medium. 

23. A method according to Claim 19 wherein step (d) comprises re^nding to 
selection of the view option by calling a view function represented in the function-calling 
information, the view function accessing and formatting the local data and displaying the 
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local data to the user, and the view function also displaying an edit option to the user, the 
method comprising the further steps: 

(e) monitoring user input for selection of the edit option; 

(f) responding to selection of the edit option by prompting the user to select 
5 displayed local data; 

(g) monitoring user input for selection of displayed local data; 

(h) responding to selection of displayed local data by presenting the selected 
local data to the user for editing via the user computer and by displaying a done 
option; 

10 (i) applying edit operations performed by the user via the user computer to 

the selected local data to generate edited local data; 

(j) monitoring user input for selection of the done option; and 
(k) responding to selection of the done option by removing the selected 
local data fiom the computer storage medium and by storing the edited local data 
15 on the computer storage medium. 

24. A method according to Claim 19 wherein step (d) comprises responding to 
selection of the view option by calling a view function represented in the function-calling 
information, the view function accessing and fonnatting the local data and displaying the 
local data to the user, and the view function also displaying a delete option to the user, 

M the method comprising the further steps: 

(e) monitoring user input for selection of the delete option; 

(f) responding to selection of the delete option by prompting the user to 
select di^layed local data; 

(g) monitoring user input for selection of displayed local data; and 

25 (h) responding to selection of di^layed local data by removing the selected 

local data from the computer stomge medium. 

25. A method according to Claim 19 wherein the local data represent at least 
one source of credit or source of funds. 

26. A method according to Claim 19 wherein the local data represent at least 
30 one postal address. 

27. A method for tracking the status of a purchase order for a product over a 
distributed network, comprising: 
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(a) storing on a computer storage medium a network address corresponding 
to a merchant, the computer storage medium accessible to a user computer, 

(b) tra n s m i tt i n g to the network address data comprising a purchase order, 
the data including a product identifier, a quantity value, payment source 
information, and shipping address information; 

(c) receiving an order tracking identifier corresponding with the purchase 

order; 

(d) storing on the computer storage medium the order tracking identifier; 

(e) presenting an order status option to a user via the user computer, 

(f) monitoring user input for selection of the order status option; 

(g) responding to selection of the order status option by transmitting to the 
network address the order tracking identifi^; 

(h) receivmg order status information; and 

Q) displaying the order status information to the user via tfie user computer. 

28. A method in accordance with Claim 27 wherein the distributed network 
comprises the World \Wde Web. 

29. A method in accordance with Claim 28 v^iierein the network address of step 

(a) identifies a Web site of the World Wide Web. 

30. A method in accordance with Claim 29 Miierein the data transmitted in step 

(b) is formatted as an HTTP POST message. 

31. A method in accordance with Claim 28 wherein: 

step (c) comprises receiving via a Web browser a MIME message including 
an order tracking identifier corresponding with the purchase order, the MIME 
message passed to a local process; and 

step (d) comprises storing on the computer storage medium the order 
tracking identifier, the storing performed by instructions of the local process. 

32. A mettiod in accordance with Claim 28 wherein the order status option of 
step (e) is included in an HTML-coded Web document, the order status option displayed 
to the user by a Web browser, the Web document including fimction-calling information 
associated with the order status option, and vsdierein: 

step (g) comprises responding to selection of the order status option by 
calling an order status function represented in the fimction-calling information 
included in the Web document, transmitting to the network address an HTTP POST 
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message including the order tracking identifier, the transmitting of the HTTP POST 
message performed by instructions of the order status fimction, the order status 
function comprising executable computer instructions stored on the computer 
storage medium; 

step (h) comprises receiving with the Web browser a second HTML-coded 
Web document including order status information; and 

step (i) comprises displaying the order status information to the user via the 
Web browser. 

33. A method for using a computer to access and display information, the method 
comprising the following steps: 

(a) establishing a conmnmication link between the computer and a second 
computer using TCP/IP protocol; 

(b) running a local process on the conq>uter, the local process displaying an 
information access option, the local process incapable of scanning an HTML file 
to generate a display on the computer screen; 

(c) monitoring user input for selection of the information access option; 

(d) responding to selection of the information access option by transmitting 
to the second computer an HTTP POST message including an information access 
request, the transmission p^ormed by instructions of the local process; 

(e) running a Web browser oh the computer; 

(f) receiving an HTML file transmitted by the second computer, and 

(g) displaying via the Web browser, information included within the HTML 

file. 

34. A method according to Claim 33 wherein the information describes usage 
of the local process. 

35. A method according to Claim 33 wherein the information describes the 
cause of an error in using or running the local process. 
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